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Abstract 


We present “Gasper,” a proof-of-stake-based consensus protocol, which is an ide- 
alized version of the proposed Ethereum 2.0 beacon chain. The protocol com- 


bines Casper FFG, a finality tool, with LMD GHOST, a fork-choice rule. We 
Prove va aAa cr different sets of 


assumptions. 
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1 Introduction 


Our goal is to create a consensus protocol for a proof-of-stake blockchain, This paper is motivated by 


the need to construct Ethereum’s “beacon chain” in its sharding design. However, the construction 
can also be used for a solo blockchain with no sharding. 


We present Gasper, a combination of Casper FFG (the Friendly Finality Gadget) and LMD GHOST 
(Latest Message Driven Greediest Heaviest Observed SubTree). Casper FFG [7] isa “finality gad- 
get,” which is an i i i 


Casper is not a fully-specified protocol and is designed to be a “gadget” that works on top 


of a provided blockchain protocol, agnostic to whether the provided chain were proof-of-work or 
proof-of-sake. LMD GHOST is participants) attest to blocks 


ln, like voting. Gasper is a full proof-of-stake protocol that is an 
ealized abstraction of the proposed Ethereum implementation. 


In Sections 2 and 3, we define our primitives, provide background knowledge, and state our goals, 
In Section 4, we give our main protocol Gasper. In Sections 5, 6, and 7, we formally prove Gasper’s 
desired qualities. In Section 8, we summarize some differences between Gasper and the actual 
planned Ethereum implementation, such as delays in accepting attestations, delaying finalization, 
and dynamic validator sets. We conclude with some thoughts and ideas for future research in Sec- 
tion 9. 


2 Setup and Goals 


The main goal of this paper is to describe and prove properties of a proof-of-stake blockchain with 
certain safety and liveness claims. In this section, we give some general background on consensus 
protocols and blockchain. As the literature uses a diverse lexicon, the primary purpose of this section 
is to pick out a specific set of vocabulary for the rest of the paper. 


2.1 Consensus Protocols, Validators, Blockchain 


Our goal is to create a (or protocol for short from this point on), which is an 
(nodes, people, etc.) to follow in order to obtain — 
en if the network is unreliable and/or if many validators are _ 


a consensus history of their state, ev 


We call the entities (people, programs, etc.) who participate in protocol validators, denoted by the 
set V. They are called “validators” because of their data-validation role in the Ethereum 2.0 beacon 
chain, though the specifics of this role are not part of our abstract protocol. Other works use many 
different words for the same concept: e.g. “replicas” in classic PBFT literature, “block producers” in 
DPoS and EOS, “peers” on Peercoin and Nxt, or “bakers” on Tezos. The 


each other on a (peer-to-peer) network, which means they can broadcast messages (basically, packets 
types of messages 


of data) to each other. In the types of protocols we are interested in, the primary 


are blocks, which collect bundles of messages. The is called the genesis block and acts 
as the initial “blank slate” state. 


eee A blockchain is just an instantiation (i.e. with specific network conditions, validators, 


etc.) of 


We do not want all blocks seen on the network to be accepted as common history because blocks — 


can conflict with each other. These conflicts can happen for honest reasons such as network latency, 


or for malicious reasons such as Byzantine refers 


to a classic problem in distributed systems, the Byzantine Generals Problem, and is used in this 
instance to describe LSE RO EEDA D. either because they are malicious 
or experiencing network latency. Graph-theoretically, one can think of a choice of history as a 
choice of a “chain” going from the genesis block to a particular block. Thus, a consensus history is _ 


! Our choice that each block has a unique parent is almost taken for granted in blockchains; one can imagine 
blockchains where blocks do not need to have parents, or can have more than one parent. See, for instance, 
Hashgraph [2]. Even the very general structure of “block” itself may be limiting! 


opomena prai ails rg nal nai piealoingceeniasounties!™'s is why we call such an instantiation 
of our protocol a “blockchain. 


Example 2.1. Assume the goal of a protocol is to keep a ledger of every validator’s account bal- 
ances. Then their collective state is the ledger, and each block captures a state transition, such as a 
monetary transaction from one validator to another (e.g., ““Yunice sends coin with ID 538 to Bureau- 
gard,”’). One type of conflict we may want to avoid is having both the aforementioned transaction 
and another transaction with content “Yunice sends coin with ID 538 to Carol” be accepted into 
consensus history, an act commonly called double-spending. The current consensus state can be 
determined by starting from a “genesis state” and sequentially processing each message in the con- 
sensus history (hopefully one that all honest validators will agree with), starting from the genesis 
block. 


2.2 Messages and Views 


In our model, a validator V interacts with the network by broadcasting messages, which are strings 
in some language. W i 


The main type of message proposes a block, which is a piece of data, to the network. Other messages 
can be bookkeeping notices such as voting for blocks (“attestation”), putting new validators on the 
blockchain (“activation”), proving bad actions of other validators (“slashing”), etc. depending on 


the specific protocol. We assume that each message is digitally signed by a single validator, which 


means we can accuratel nd attacks such as impersonation of - 


Due to network latency and dishonest validators (delaying messages or relaying incorrect informa- 
tion), v 

network; we formalize this by saying that a validator either sees or does not see each message given 
to the network at any given time. 


Each message may have one or more dependencies, where each dependency is another message. At _ 


a 
fined recursively. We now define the view of a validator V at a given time T', denoted as view(V, T), 

as the set of all the accepted messages the validator has seen so far. We also have a “God’s-eye- 
view” that we call the network view, defined to be the set of accepted messages for a hypothetical 
vali i (this 
includes messages sent by a malicious validator to only a subset of the network). We will treat the 


network as a “virtual validator”, so we use view(NW, T) to denote the network view at time T. For | 


renee ee ae Finally, since usually the context is that we are talking about 


a specific point in time, we will usually just suppress the time and use notation such as view(V) to 
talk about view(V, T), unless talking about the specific time is necessary. 


Example 2.2. At time T, suppose validator V sees the message M with content “Yunice sends coin 
number 5340 to Bob,” but has not yet seen the message W” containing “Yunice obtains coin number 
5340” (which is on the network but has not yet made its way to V). Also suppose that in our protocol 
M depends on M’ (and no other message), which captures the semantic meaning that we need to 
obtain a coin before spending it, and that V cannot and should not act on M without seeing M’. In 
this situation we say that V has seen but has not accepted M, so M ¢ view(V, T). However, the 
network has seen both; so if the network accepts M’, we have M € view(NW, T). 


We now make some assumptions on the structure of views: 


‘ (with no signature) 
corresponding to a single agreed-upon genesis block, denoted , with no dependen- 


cies (so it starts out automatically accepted into all views). 


?We model the validators as sending a single message to an abstract “network,” which handles the message. 
In practice, it may be part of the protocol that e.g., every honest validator rebroadcasts all messages that they 
see, for robustness. We consider these implementation details not important to our paper. 


e Each block besides Bgenesis refers to (and depends on) a parent block as part of its data. 


Thus, we can visualize view(V) asa directed acyclic graph (in fact, a directed tree? 


at Bynes With an edge B + B! if B is the parent of B’, in which case we say 
child of B. We call these Parnes edges to differentiate from other types of edges. 


e We say that 


such a protocol would then be a sequence of r ees 
We say B isan 


e say two blocks B and B’ conflict _ 


e The above setup implies i i i 
Bgenesis to B, and this us we do not 
need to include a view as part of its definition). We call this the chain of B, or chain(B). — 


B genesis 


ZN 


A 


aE 


E 


Figure 1: A graph visualization of a view (only visualizing blocks and not other messages) that 
occurs in the types of protocols we care about. 


Example 2.3. See Figure 1 for an example of a view, limited to blocks. Arrows portray parent- 
child edges. The blocks in a view form a tree rooted at a single genesis block Beenesis. Here 
blocks C and D conflict (as well as Æ and D). E has the longest chain, which is chain( E) = 
(Bgenesis, A, B, C, E). 


There are some technicalities to our wording in this section that motivates our definition of views 
but are not very important to the core of this paper. To not distract the reader, we defer these details 
to Appendix A. 


2.3 Proof-of-stake 


The first and most influential approach to blockchain protocols i is Bitcoin [15], using a proof-of-- 
odel. This approach makes it , using the simple ~ 
” Miners 
(the analogy of validators) simply propose blocks to build on the heaviest chain (the chain with the 


most amount of computational work), which does not mathematically guarantee any non-genesis 


with a block once other miners build on top of it. Then the consensus history is simply the chain 
i which ideally keeps growing. The elegance of proof-of-work is 


paid for by the expensive cost of computational work / electricity / etc. to propose a block. 


ain, where a validator’s voting power is 


Instead of using computational power 


to propose blocks, i : exchange, 
of mat ical ti : , ee 


This statement already captures the primary reason we define both seeing and accepting; the blocks a 
validator accepts must be a single rooted tree, though the blocks a validator sees can be some arbitrary subset 
of the tree, so limiting our attention to the tree allows cleaner analysis and avoids pathological cases. Beyond 
this reason, the distinction between the two words is unimportant for the rest of this paper. 


In this paper, we want to create a 


“easy.” We now shift our paper’s focus to a family of blockchain designs with proof-of-stake in 


mind. ® 
To start, we assume we have a set of N validators V = {Vi,..., Vn} and that 

, . We make 
the further assumption that s 


total stake is N. All of our operations involving stake will be linear, so this scaling does not change 


the situation and makes the bookkeeping easier. We assume validator sets and stake sizes are fixed 


for the sake of focusing on the theoretical essentials of the protocol. We address issues that occur 
when we relax these conditions in practical use in later sections, especially Section 8. 


The main ingredients we need are: 


e A fork-choice rule: a function 
block B. This choice 


called the enirigi : ; 
tuitively, a fork-choice rule j 
. This rule is similar with the “heaviest 


chain rule” used by Bitcoin. 


e A concept of finality: formally, a deterministic function F that 
r 


. Intuitively, finalized blocks ee a 
> or “what the blockchain is sure 


of” 


ese are 


t, with the idea that violators’ stake would be 
slashed, or destroyed. Slashing conditions 

(the protocol can reward honest validators for catching dishonest validators violating the 
conditions, for example). 


The key concept we use to define these ingredients are ich ar 


or voting in protocol-breaking ways, we enforce slashing conditions which can be used to` 


Bygenesis blocks: 
y 


et A attestations: O 
ee ee ee [A ]#-— a 


B depends on A 


| Byenesis | +4 HB HE 


The chain of C or chain(C) 


Figure 2: An ideal view with both blocks and attestations. 


One can see an idealized version of the protocol we will present in Figure 2; in each time period, 
a new block is created with the parent block being the last head of chain (which is ideally just the 
last block created), and validators in the corresponding committee all perfectly attest to the new 
block. In less idealized situations, the blocks may fork, issi ions, etc. 

. In 
Section 4 we will define all the details. 


2.4 Byzantine Validators, PBFT 


an . We 
typically assume This constant can be traced 
to (PBFT) from [8], a classic consensus protocol in byzantine 
tolerance literature; PBFT ensures that the system runs correctly as long as less than f of the replicas 
(synonymous with our validators) are byzantine, as proven in [3]. This constant 4 tolerance appear 
frequently in many works based on PBFT (the main idea is that peA E 

, such as in our proof in Section 5), with Casper FFG [7] being the most 
directly relevant to our work, which we review in Section 3.1. 


In a protocol, we call 


Concretely, we define a blockchain running the protocol to be 


and most of our results 
will take the form “at any time, 


.” because we really cannot guarantee having any good properties when we have many byzantine 


“actors, so Also note that having (1/3)-slashable is 
å . 
ee cause if we oa had the latter an 


One of the most important aspects of PBFT is that it works under asynchronous conditions, which 


means we have no bounds on how long it may take for messages to be received. Thus, it is robust to 
the demands of blockchains and cryptocurrencies, where we often worry about adversarial contexts. 
We will discuss synchrony assumptions further in Section 2.6. 


2.5 Safety and Liveness 


The ultimate goal for the honest validators is to grow a finalized chain where all blocks form “log- 
ically consistent” state transitions with each other (despite having validators potentially go offline, 
suffer latency problems, or maliciously propose conflicting state changes). Formally, this translates 
to two desired properties: 


Definition 2.4. We say a consensus protocol has: 


e 
E A consequence of having safety is that any validator view G’s finalized blocks 


block and ends at the last finalized block, which we w 


e liveness, if the set of finalized blocks can actually grow. There are different ways to define 


liveness. For our paper, we say the protocol has: 


On first glance, the latter implies the former, but the situation is more subtle; the former is a 
purely non-probabilistic property about the logic of the protocol; the latter requires (poten- 
tially very strong) assumptions about the context of the implementation to guarantee that 
the protocol “usually works as intended.” We discuss this contrast further in Section 7.3. 


Our main goal in this paper is to prove these vital properties for our main protocol in Section 4. 


Remark (Syntax versus Semantics). It should not be immediately obvious that chains have anything 
to do with logical consistence of state transitions, and this requires more work on the part of the 
protocol designer to ensure. For example, one can dictate a protocol where a block that allows a user 
to spend a coin S forbids an ancestor block from using S in another transaction. In this situation, 
if Xander obtained a coin S from block B, and writes two blocks By and B,, such that B,’s data 
includes Xander paying S to Yeezus and B,’s data includes Xander paying S to Zachariah, then 


the logical idea that these actions are inconsistent corresponds to the graph-theoretical property that 
B, and B, conflict as blocks. The language of chains and conflicting blocks is enough to serve any 
such logic, so we assume in our paper that the syntax of what blocks can be children of what other 
blocks has already been designed to embed the semantics of logical consistency, which allows us to 
ignore logic and only think in terms of chains and conflicting blocks. 


2.6 Time, Epochs, and Synchrony 


In our model, 


defined as some constant number of seconds i 
epoch to be (tentatively 


The main purpose of epochs is Co egBe ema nt BIER. the boundaries between which can be 
thought of as “checkpoints.” This allows concepts from Casper FFG to be used, as we will see in 
Section 3.1. 


We should not assume the network is guaranteed to have the validators see the same messages at 
any given time, or even that different validators have the same view of time. The study of consensus 
protocols address this issue by having different synchrony conditions, such as: 


e asynchronous system has explicit upper bounds for time needed to send messages between 
nodes; 


e an asynchronous system has no guarantees; recall that PBFT [8] works under asynchrony. 


e a partially synchronous system can mean one of two things depending on context: (i) 
pe ee rr enn NU Nr 


Geienine AEE The work [10] establishes bounds on 
ault tolerance in different fault and synchrony models, focusing on partial synchrony. 
For us, we ma 


u 


(where T and t are both in units of slots) i 


Remark. Itis possible to e.g., receive messages “from the future.” Suppose Alexis sends a message 
timestamped at 00:01:30 PT and Bob receives it 1 second later with a clock that is 3 seconds behind 
Alexis’s. Bob sees this 00:01:30 PT message on his own clock timestamped at 00:01:28 PT because 
he is a net total of 2 seconds behind. (honest) 


(i.e., do not add it into their view 


` timestiiihps hit the message’s timestamp. This allows us to assume again, by 
honest validators) in earlier slots than they should. 


3 Main Ingredients 


3.1 Casper FFG 
Buterin and Griffith introduce Casper the Friendly Finality Gadget (FFG) in [7]. This tool defines 
the concepts of justification and finalization inspired by practical Byzantine Fault Tolerance (PBFT) 


literature. Casper is designed to work with a wide class of blockchain protocols with tree-like 
structures. 


° ir di i which has height 
0). Equivalently, the height of B i 

e We define chnatngineslogks to be eeehe pinkin asonati (in 
[7], H = 100). We define the checkpoint height h( B) for a checkpoint block B as the 


height of B divided by H, which is always an integer. Thus, we can think of the subset of | 


checkpoints in the view as a subtrees containing only blocks whose heights are multiples of 
TP 
S. e can 


e choices of A and B depend on the underlying blockchain 
a part of Casper. , which is Ane 
H = 100, it is possible for , in which case 


their underlying blockchain may want them to send an attestation from checkpoint block 
100 to checkpoint block 300. 


Remark. Observe we setup time in units of slots, which are grouped into epochs. This is analogous 
to (but not exactly identical to) block heights and checkpoint blocks. We discuss this further in 
Section 4.1. 


Casper FFG also introduces the concepts of justification and finalization, which are analogous to 
phase-based concepts in the PBFT literature such as prepare and commit, e.g., see [8]: 


e TujagviewgGsagcheckpointjblockpBpisyjustified (by a justified checkpoint block A) qi 
: ine f aii Nara ar 

ke. Equivalently, we say there is a supermajority link A 5 B. This is 

he view in question may have or have not seen all 


a view-dependent condition, because t 


(or even having seen the block B itself), 


° In a view G, if A € J(G) (equivalently, A is justified), and A => B is a supermajority link 


, then we say 


Finally, Casper introduces slashing conditions, which are assumptions about honest validators. 


When they are broken by a validator V, (destroy v’ s stake 
>) 


and 5 


Definition 3.1. The following slashing conditions, when broken, cause a validator violating iheni 
to have their stake slashed: 


As Casper is a finality gadget and not a complete protocol, it assumes the underlying protocol has 
: : f . ki 
to make one (and only one) attestation. It is assumed tha 


t honest validators following the underlying 
ee For example, if the protocol asks to make exactly one attestation per 
epoch, then honest validators will never violate (S1). 


The main theorems in Casper are (slightly paraphrased): 


Theorem 3.2 (Accountable Safety). Tw 


o checkpoints on different branches cannot both be finalized, 
ee eee OER Sane SURUR Stele Sessoms total prove yiolatesdbemrpiace! (and thus can 
be held accountable). 

Theorem 3.3 i i ). Ita i i i 
P 


Remark. Palmskog etal. [17] provided a mechanical proof assistant for Casper FFG’s accountable 
safety and plausible liveness in the Coq Proof Assistant. The authors modified the blockchain model 
in Coq, Toychain, to use for the Casper FFG with Ethereum’s beacon chain specs in order to see how 
Casper FFG’s proofs will work in practice. 


3.2 LMD GHOST Fork-Choice rule 


The i i (GHOST) is a fork-choice rule introduced by Som- 
olinsky and Zohar [20]. Intuitively, GHOST is a greedy algorithm that ee 


? Zamfir [22], in looking for a “correct-by-construction” con- 
sensus protocol, introduces a natural adapation of GHOST that happens to be well-suited for our 
setup*. We call this variant Latest Message Driven Greediest Heaviest Observed SubTree (LMD 
GHOST), which we can define after having a notion of weight: 


Definition 3.4. Given a view C, Let M be the set of latest attestations; one per validator. The weight 
the sum of the stake of the validators i whose last attestation in M is 


Algorithm 3.1 LMD GHOST Fork Choice Rule. 


procedure LMD-GHOST(G) 
: Be Beenesis 


1: 
2 
3: M + the most recent attestations of the validators (one per validator) 
4: while B is not a leaf block in G do 
5: B + argmax w(G, B’, M) 
B' child of B 
6 (ties are broken by hash of the block header) 
7 


return B 


Pa 
1 o go 
tO 


Figure 3: An example of the LMD-GHOST fork-choice rule. The number in each block B is the 
weight (by stake), with all attestations (circles) having weight 1 in our example. A validator using 
this view will conclude the blue chain to be the canonical chain, and output the latest blue block on 
the left, with weight 3, to be the head of the chain. 


The idea of LMD GHOST is that at any fork, we use the weights of the subtrees created by the fork 

, as evident from 
the name of the algorithm. We will always end up at a leaf block, which defines a canonical chain. 
See Figure 3 for a graphical visualization. In [22], LMD GHOST was tied to a particular protocol. 
Our presentation of it in this paper treats the specifics of attestations as details to be filled in by the 
protocol, like how Casper does not specify details on how blocks are constructed. We merely need 


that the concepts of blocks and attestations exist, and then LMD GHOST defines an algorithm to 


. In Section 4 we will modify the rule to satisfy our other purposes. 


“This part of the field can create phantasmal confusion: the name of [22] is “Casper the Friendly GHOST,” 
which introduces Casper CBC (also see [5]), a completely separate protocol from Casper FFG. Our paper is in 
some sense recombining these two ideas, but the “Casper” in [22] is very different from Casper FFG. 


10 


°3 


4 Main Protocol: Gasper 


We now define our main protocol Gasper, which is a combination of the GHOST and Casper FFG 
ideas. The main concepts are: 


; However, a block may appear more 
(this is a nuance not found in Casper; we 
expound on this in Section 4.1), so 

Gea to disambiguate. These will be called epoch boundary pairs, or pairs for short. 


° ane validators are partitioned into committees in each epoch, with one com- 
(0) $ 


t : : 


Then, 
(which is hopefully the block just proposed) with the fork-choice rule HLMD GHOST (a 
slight variation of LMD GHOST). 


e Justification and Finalization: these concepts are virtually identical to that of Casper FFG, 
excep SEH GSE Sle cS USL TCE ETE aE CHUSCIURSTE TBST 


i.e., given a view G, J(G) and F(G) are sets of pairs. 


4.1 Epoch Boundary Blocks and Pairs 


Recall any particular block B uniquely determines a chain, chain(B). 


the > 
. Let the latest such block be LEBB(B), or the last epoch boundary 
_ block (of B). We make a few observations: 


e For every block B, EBB(B,0) = Bgenesis- 


° tenses.” some epoch j, B will be an epoch boundary block in 


However, without such assumptions, a block could be an epoch boundary block in some 


TS. 


To disambiguate situations like these, we add precision by introducing epoch boundary pairs (or 

pairs for short) (B, j), where B is a block and j is an epoch. Our main c ts of justification and 

finalization will be done on these pairs. Given a pair P (B, 4), we sa fed OEE 
using the notation aep(P) = j, which is not necessarily the same as ep( B). 


Epoch 0 Epoch 1 


65 


LEBB(65) = 64 


N 
Be ESEE 


“63” x fa as eh E See 66 LEBB(66) = 63 


EBB(66, 1) = (63, 1) 


Figure 4: Example of epoch boundary blocks and pairs. Blocks are labeled with their slot numbers. 
“63” is not an actual block but illustrates the perspective of 66 needing an epoch boundary block at 
slot 64 and failing to find one. 


Example 4.1. Suppose blocks (labeled by slots) form a chain 63 «+ 64 + 65 and there is a fork 
63 + 66. Then EBB(65,1) = 64 since 64 is in chain(65). When we try to find EBB(66, 1), we 
look for block 64 because we are in epoch 1 and realize it is not in chain(66), so we have to look 
backwards and “pull up” block 63 from the previous epoch to serve as the epoch boundary block in 


11 


this chain. This is visualized by the dashed components in Figure 4. Observe even though aep(63, 1) 
and ep(63) = 0, e 


Remark. We further address why we use pairs instead of checkpoint blocks. Casper FFG is a 
“finality gadget,” meaning it is designed to place a layer of finality on top of a blockchain which has 
which gives a steady new supply of checkpoint blocks. Probabilistic liveness 

. For the safety part of the design, we would want to make fewer 


a OOOO O 


As an example, block B may be the head of the chain from epoch 1, but be currently at epoch 3 
with no new block built on top of B. In the original Casper FFG, we expect probabilistic liveness 
so we would have a different checkpoint at every epoch. However, when we have no synchrony 
assumptions, in the analysis we would need to differentiate the idea of “checkpoint in epoch 2” 
and “checkpoint in epoch 3” even though the best candidate for both is B, which is itself still 
only in epoch 1! This naturally induces the concepts 


i 


Also, Casper FFG makes no assumptions about time in the underlying blockchain — only block | 


The 


1 
a system clock, with blocks coming at fairly irregular times. s a proof-of-stake protocol, 


, SO instead the To capture 
this notion of time, each object in our blockchain then naturally requires the knowledge of both the 


aptured in a block) and the time (captured in the epoch count), which also leads naturally to 


the idea of pairs. 


4.2 Committees 


The point of . To start, assume 
the 


{1,2s005;N} > {1,2,005.N}. In the scope of this article, we assume we get these random per 
Recall time is split into epochs, of C slots each. i i 
epoch j. Its role is to e 


responsibilities for one slot of the epoch. To be precise: 


e 
So, S1,..., Sc—1 (we assume CN for easier notation; dealing with “roughly equal” size 
committees does not change the essence of our approach). 


e Therefore, 
Note, for an epoch j, the sets So, S1,...,S¢_1 


partition the entire set of validators {V,,..., Vy } across all the slots of epoch j, as desired. 


To summarize, in each epoch j, pj allows us to shuffle the validators into C committees. Our work 
does not assume more than this intuition. 


4.3 Blocks and Attestations 


Now, in each slot, the protocol dictates 2 types of “committee work” for the committee assigned 
to their respective slot: i 

Both proposing blocks and attesting 
mean immediately adding a corresponding message (a block and an attestation, respectively) to 
the validator’s own view and then broadcasting the message to the network. Recall the messages 
proposing (non-genesis) blocks and publishing attestations have digital signatures. 


> Achieving non-exploitable randomness on the blockchain is itself an interesting problem, stimulating re- 
search such as verifiable delay functions; however, in this article we will take this randomness for granted. 


12 


which is a variation of the LMD GHOST fork-choice rule. 
’s definition requires concepts that we have not introduced yet, so we delay its definition to 
Section 4.6. For now, the only thing we need to know is, like LMD GHOST, HLMD() takes a view 
G and returns a leaf block B as the head of the chain, making chain(B) the canonical chain of G. 


We now present the responsibilities of the protocol during slot i = jO +k, where k € {0,1,...,C— 


le "=~ bil 


Definition 4.2. At the beginning of slot i = jC + k 
member of the committee S% of epoch j, 


canonical head of the chain in hi 


which is a message containing: 


1. slot(B) = i, the slot number. 


2. P(B) = B’, a pointer to the parent block; in other words, we always build a block on top 
of the head of the chain. 


3. newattests(B), a set of pointers to alll the artestations (to be defined next) 
4. Some implementation-specific data (for example, “Yunice paid 4.2 ETH to Brad” if we are 


tracking coins), the semantics of which is irrelevant for us. 


, i.e., the first 


aA baie NEY etc a hal Dat Re cic tdci ea a (so for example, if we 


In typical (honest) behavior, we can assume each slot number that has a block associated with it 
also has at most one such block in view(NW). By default, B is the unique block with slot 0. 


Saal 


. For example, every time a digitally 
ock enters the view of a validator, the validator can immediately check if the block proposer 
is the unique person allowed to propose a block for that respective slot. A validator can also prove 
the same person proposed two blocks in the same slot by just pointing to both blocks. 


Definition 4.3. 
, > , which is a message 


containing: 


1. slot(a) = jC + k, the slot in which the validator is making the attestation. We will also 
use ep(q) as shorthand for ep (slot(@)). 


2. . We will have , and 


3. A checkpoint edge \J(a) Ys LE(a). Here, LJ(a) and LE(q) are epoch boundary pairs in 
view(V, i + 1/2). We define them properly in Section 4.4. 


For dependencies, « depends on block(a). So we ignore anstestation uni the bloskitin attesting? 
to is accepted into our view (this is one of the bigger differences between theory and implementation; 


we discuss this more in in Section 8). 


Intuitively, © is doing two things at once: it i 


(akin to Casper’s 


checkpoint blocks). 
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4.4 Justification 


Definition 4.4. Given a block B, we define® vi , the view of B, to be the view consisting of — 
i i We define ffgview(B), the FFG view of B, to be 


The definition view(B) i 


rea ar so 
view(B) “focuses” the view to chain(B) and 


Casper FFG operates only on epoch boundary pairs, so the FFG view of a block 
B extracts exactly the information in chain(B) that is relevant to Casper FFG. 


in which 


or NW) into the argument. Intuitively, 


We now define the main concepts of justification. To start, recall an attestation a for Gasper contains 


a checkpoint edge LJ(a) ea LE(a), acting as a “FFG vote” between two epoch boundary pairs. 
After a couple of new definitions, we can finally explicitly define these notions. 


Definition 4.5. We say there is a supermajority link from pair (A, j’) to pair (B, j) if the attestations | 
In this case, we write (A, j’) > (B, j). 
Definition 4.6. Given a view G, we define the set J(G') of justified pairs as follows: 


© (Beenesis,0) € J(G); 

o if (A, j") € J(G) and (A, j') = (B, j), then (B, j) € J(G) as well. 
If (B, j) € J(G), we say Bis justified in G during epoch j> 
Definition 4.7. Given an attestation a, let B = LEBB(block(a)). We define: 


1. the the 


2. 
While we define J(G) for any view G, we are typically only interested in = i 
We can think of e 


Epoch 0 Epoch 1 Epoch 2 


129} 131 >--- > 180 180 } 193 


Figure 5: A validator’s view G as she writes an attestation in epoch 3. During epoch 1, latency 
issues make her not see any blocks, so block 64 is both EBB(193, 1) and EBB(193, 2). She ends up 
writing an a with a “GHOST vote” for block(a@) = 193 and a “FFG vote” checkpoint edge (single 
arc edge) (64, 2) nue (180, 3) for a. We use slot numbers for blocks, so block 0 is just Bgenesis- 
Blocks in red are justified (in G). Double edges corresponding to supermajority links. 


Example 4.8. A validator runs HLMD(G) on her view G to obtain her head of the chain, which is 
block 193. She is then supposed to attest to 193 with an attestation a. 


On chain(193) portrayed in Figure 5, LE(a@) = (180, 3), even though ep(180) = 2, because our 
attestation has epoch 3, and we were looking for 3 x 64 = 192 but did not see it (one can imagine, 


ĉWe have tyrannically overworked the notation view() by this point, but there should be no ambiguity when 
we know the type of its parameter. 
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like in our figure, that we “pull up” block 180 to show that it is EBB(193,3)). In ffgview(193) = 
view(180), the last justified (by epoch number, not slot) pair is (64, 2), so LJ(a) = (64, 2). 


Note that this relies on view(180) to include attestations worth at least (2N/3)-stake pointing to 
(64,2). It would be possible to have a case where this did not happen by 180, but the chain does 
see (2N/3) worth of attestations by 193. In this case, (64,2) is in J(G), but (64,2) is not in 
J (ffgview(193)), so the resulting checkpoint edge would be, e.g., (64, 1) 3 (180, 3) instead, as- 
suming the attestations for (64, 1) are in view(180). The checkpoint edge could even end up being 
(0,0) aa (180, 3), if 180 did not see those attestations; note that this is very possible if the attesta- 
tions for (64, 1) were only included in the blocks that forked off of chain(193) (such as block 130), 
as the forking may be an indication of network problems causing those attestations to be temporarily 
unavailable to validators on chain(193). 


Everything here is analogous to Casper FFG. Inside the chain of block(a) is a sub-chain created 
by the epoch boundary blocks of that chain, starting from Beenesis and ending at B = LEBB(a). 
We want to focus on this subchain of blocks (represented by pairs to allow for boundary cases) and 
justify epoch boundary pairs with many attestations; this sub-chain is exactly what’s captured by 
ffgview(block(a))). œ is a vote to transition from some last justified pair (B’, j’) to the new pair 
(B, 7), visualized as the checkpoint edge (A, 7’) AN (B, j). If (2N/3) stake worth of such votes 


happen, we create a supermajority link (A, 7’) á (B, j) and justify (B, 7). 


4.5 Finalization 


Given our notion of justification and a new fork-choice rule, we are now ready to define the notion 
of finalization. the sense that 
v. 


Definition 4.9. For a view G, we say Hanis sdinaliged (specifically, k-finalized) in G if (Bo, j) = 
(Beenesis, 0) or if there is an integer k > 1 and blocks B,,..., By, € view(G) such that the following 


holds: 
© (Bori) (Bish +1) (Bes j +E) are adjacent epoch boundary pairs in chain( B4); 
e (BoJ) (81+ 1); -- odian 


We define F(G) to be the set of finalized paifSlifi the view G; we also say that a block Bis finalized” 
if (B, 9).€ F (G) forsome epochs.) 

We expect 1-finalized blocks for the vast majority of time. Specifically, this just means we have 
blocks Bo and Bı such that (Bo, 7) is justified in G and (Bo, j) er (Bı, j + 1), or “a justified 


epoch boundary block justifies the next adjacent epoch boundary block.” This is essentially the 
original definition of finalized i in [7]. With (1/2)-synchrony and without implementation details that 


ages, we should only get 1-finalization. 
(see Section 8.3) are 
relevant. 


Remark. In Figure 6, we see some examples of finalization. On the left, we have 1-finalization, 
which is what we expect to happen in the vast majority of the time. At the center, we have an example 


of 2-finalization to account for attestation delays. 
illustration; it takes some contrived orchestration to create. In practice, 
for finalization in [11] does not even include finalization for k > 3. See Section 8.5. 


If we define a set of blocks F as finalized and prove safety for them, then safety remains true 
automatically if we change the definition of finalized to any subset of F', because safety is defined 
by the lack of incomparable pairs of finalized blocks. Thus, it does not hurt to define a very general 
class of blocks as finalized if we can prove safety. This is why we include all k in our definition; the 
more general definition is easier to analyze. 
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Figure 6: Illustrative examples of Definition 4.9 for k = 1,2,3, respectively. Double arrows are 
supermajority links. The blue block is the one being finalized in each case. 


4.6 Hybrid LMD GHOST 


We now have enough notation to define HLMD. Since the final design is fairly complicated at 
first glance, we first present Algorithm 4.1, a “prototype” version; simply put, it starts with the last 
justified block in the view and then runs LMD GHOST. It is not obvious (B z, j) should be unique, 
but it can be proven to be well-defined as a consequence of Lemma 4.11 when the blockchain is not 
(1/3)-slashable. For implementation it is costless to add a tiebreaker (say via block header hash). 


Algorithm 4.1 Prototype Hybrid LMD GHOST Fork Choice Rule 


1: procedure HLMD(G) 
2: (B7,7) < the justified pair with highest attestation epoch j in G 
Be By 
M < most recent attestations (one per validator) 
while B is not a leaf block in G do 

B 4+ argmax w(G, B’, M) 

B' child of B 
(ties are broken by hash of the block header) 


return B 


CO oe e e a 


However, using this prototype will run into some subtle problems. Because the “FFG part” of an 
attestation is a vote between epoch boundary pairs, and LJ(B) depends only on ffgview( B), we can 
think of the “last justified pair in a chain” as “frozen” at the beginning of every epoch, which does 
not mix well with the “non-frozen” (Bj, 7) being instinctively defined as the last justified block in 
our entire view, as the latter definition can shift during an epoch (the reader is encouraged to think 


of eae with this, as an exercise). Thus, 
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Another problem occurs when the algorithm forks: Die E eon eaten eas 
i i i As a result o s mismatch, we can create patho- 


logical situations wher 


To resolve these issues, first 
; formally, this means when 


branches with leaf nodes By where LJ(B;) has not “caught up” to (By, j); formally, v eate a 
auxiliary view G” from G that eliminates the problematic branches. These fixes give Algorithm 4.2, 


the final design. 


Algorithm 4.2 Hybrid LMD GHOST Fork Choice Rule 


1: procedure HLMD(G) 
2: L + set of leaf blocks B; in G 
3: (B3, j) < the justified pair with highest attestation epoch j in 
J (ffgview(B;)) over By € L 
4 L’ + set of leaf blocks B; in G such that (B;,7) € J(ffgview(B;)) 
5 G” + the union of all chains chain(B;) over B; € L’ 
6: Be By 
7: M + most recent attestations (one per validator) 
8: 
9 


while B is not a leaf block in G’ do 
Be argmax w(G’, B’,M) 
BY child of B 
10: (ties are broken by hash of the block header) 


11: return B 


A dual (and possibly simpler) way of understanding Algorithm 4.2 is from the perspective of a 


state-based implementation of the protocol. We can think of each chain of a leaf block B; as storin 
the state of its own last justified pair. Dae ee E E CIE 
updates the GHOST-relevant list of latest attestations M but not the FFG-relevant justification and- 


4.7 Slashing Conditions 


In this subsection, we add slashing conditions, analogous to those from Casper in Definition 3.1. 
We prove a couple of desired properties, after which we are ready to use these conditions to prove 
safety of Gasper in Section 5. 


Definition 4.10. We define the following slashing conditions: 


(in other words, the 


Lemma 4.11. In a view G, for every epoch j, there is at most 1 pair (B, j) in J(G), or the 
blockchain is (1/3)-slashable. In particular, the latter case means there must exist 2 subsets V1, V2 
of V, each with total weight at least 2/3, such that their intersection violates slashing condition 
(S1). 
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Proof. Suppose we have 2 distinct pairs (B, j) and (B’, 7) in J(G). This means in epoch j, more 
than a total stake of 2N/3 attested with a checkpoint edge to (B, 7) and more than 2N/3 stake 
attested with a checkpoint edge to (B’, j). These are our desired V; and V2. 


Remark. The importance of Lemma 4.11 is that assuming reasonable conditions w are not (1/3)- 


Proof. First, notice an honest validator cannot violate (S1) because each validator is assigned to 
exactly one committee in each epoch, and is thus asked to attest exactly once per epoch. Thus, it 
suffices to consider (S2). 


Suppose an honest validator V is about to write an attestation that violates (S2) in epoch u. This 
means there are epochs r < s < t < u where in epoch t, V wrote an attestation a; with checkpoint 


edge (Ba, s) A (B3, t) and the protocol is telling V now to write an attestation a,, with checkpoint 


edge (B1,r) 4 (B4, u). This means running HLMD GHOST on V’s current view ends up at some 
leaf block B, which must be a descendent of B4 such that LE(B) = (B4, u). 


Because V wrote a; in epoch t < u, we know (B2, s) was a justified pair in ffgview() of some leaf 
block at that point in epoch t. As justified blocks remain justified when their chains grow, we know 
that now in epoch u, the starting justified pair (B J, j) as defined in HLMD GHOST (Algorithm 4.2) 
must satisfy 7 > s. Since s > r, we know that j > r. 


However, because of the filtering L’ in Algorithm 4.2, we know that the resulting leaf block B of 
running HLMD GHOST (in epoch w) starting at (By, j j) must satisfy (Bz, j) € J(ffgview(B)). 
Since LJ(B) € J(ffgview(B)) by definition and LJ(B) = (B1, r), we know j < r, a contradiction. 
Therefore, the protocol cannot force an honest validator to violate (S2). 


4.8 Rewards and Penalties 


A validator should be rewarded (i.e. have stake increased) 
eroen dl (in the beacon chain specs [11], u reward) 
11 


attester reward). Meanwhile, a 


The reward and penalty amounts can be adjusted based on the security level that needs to be 

, and the game theory of the situation should be such that validators are incentivized to 

s. Additionally, it is worth considering more 

complex incentives, such as incentivizing validators to catch other misbehaving validators. While 

this makes for potentially interesting game theory work, adding a layer of analysis of these param- 

eters is distracting for the scope of this paper, where we want to focus on the consensus aspect of 

Gasper. To be pragmatic, we abstract this analysis away by assuming these reward and penalty 
mechanisms provide enough game-theoretical incentives such that the following holds: 


Honest validators follow the protocol. 
e Any honest validator seeing a slashing condition violated will slash the dishonest validator. - 


5 Safety 


Recall our main goals are proving safety and liveness. In this section, we prove safety, which is 
done similarly as in Casper FFG [7]; the main differences are that 

as opposed to Casper’s checkpoint blocks) and our finalization definition is more complex. 
Thus, we need the following Lemma, which is necessarily more complicated than its counterpart 
idea in Casper. 
Lemma 5.1. In a view G, if (Br, f) € F(G) and (By, j) € J(G) with j > f, the 
a , or the blockchain is (1/3)-slashable — specifically, there must exist 2 subsets V1, V2 
of V, each with total stake at least 2/3, such that their intersection all violate slashing condition 
(S1) or all violate slashing condition (S2). 
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Proof. Anticipating contradiction, suppose there is a pair (B;,j) with j > f and By is not a 


descendant of By. By definition of finalization, in G, we must have (Bp, f) a (By, f + k), where 
we have a sequence of adjacent epoch boundary pairs (Br, f), (B1, f +1),..., (Bk, f +k). 


Since (B3, j) is justified and B; is not a descendant of By, without loss of generality (by going 
backwards with supermajority links), we can assume (B, 7) is the earliest such violation, meaning 


we can assume (B, 1) 4 (B, j) where! < f but j > f (here we are using Lemma 4.11, which tells 
us no two justified blocks have the same aep(), else we are done already with 2 validator subsets 
of weight 2/3 each violating (S1); this is why we do not worry about the equality case). Since 
B,,..., By are all justified but are descendants of Bpr, we know B, cannot be any of these blocks, 
so we must have 7 > f +k. This means the view G sees some subset V; of VY with total stake more 
than 2/3 have made attestations justifying a checkpoint edge (B, l) => (B,,7), so for any such 
attestation a1, aep(LJ(a1)) = l and ep(a1) = j. Similarly, G also sees more than 2/3 weight 
worth of validators Vz have made attestations justifying (Br, f) > (Bx, f + k) so for any such 
attestation a2, aep(LJ(a2)) = f and ep(a2) = f + k. Thus, for anyone in the intersection V1 N V2, 
they have made two distinct attestations a of the former type and az of the latter type. Because 


l<f<ft+tk<j, 


we know 
aep (LJ (a1)) < aep (LJ (az)) < ep (az) < ep (a1), 
which allows them to be provably slashed by (S2). 


We are now ready to prove safety. 


Theorem 5.2 (Safety). In a view G, if we do not have the following properties, then G is (1/3)- 
slashable. 


MO O TA 
2. if (B, j) € F(G), then B is in the canonical chain of G. 


Proof. The first property is straightforward from the definitions of F (G) and J(G), so we omit the 
proof. 


The definition of Algorithm 4.2 shows that the canonical chain always goes through the justified 
pair with highest attestation epoch 7, so by Lemma 5.1 must go through the highest finalized pair in 
F'(G). Thus, it suffices to show that no two finalized blocks conflict, because then all the finalized 
blocks must lie on the same chain, which we just showed must be a subset of the canonical chain. 


We now show that if (B1, f1), (Bo, fo) € F(G) but By and B2 conflict, then G is (1/3)-slashable. 
Without loss of generality, fo > fı. Since (Bo, f2) is finalized, it is justified, and we can apply 
Lemma 5.1. This shows that either Bj must be a descendant of Bı (assumed to be impossible since 
they conflict) or G is (1/3)-slashable, as desired. 


Finally, to get our original notion of safety from the Theorem, note that the definition of finalized — 
S, 


6 Plausible Liveness 


This section is similar to Casper FFG [7, Theorem 2]. Since our setup is more complex (in particular, 
Algorithm 4.2 is much more involved), the results do not immediately follow from the previous 
result, despite having the same main ideas. 


To do this, we give an auxiliary definition: given a chain c = chain( B) and an epoch j, we say that 
cis stable at j if LJ(EBB(B, j)) = (B’, j — 1) for some block B’. 


Theorem 6.1. 


= 
No} 


Proof. Suppose we are starting epoch j. Specifically, suppose our current slot is 7 = Cy; then 
it is plausible (by having good synchrony) for everyone to have the same view. In particular, the 
proposer, who is plausibly honest, would then propose a new block B with slot 7, which is a child of 
the output block of HLMD() run on the old view. Call this current view (including B) G and define 
c = chain(B). Keep in mind that LEBB(B) = B; we are introducing a new epoch boundary block. 


Now, we claim that it is plausible that c extends to a stable chain at the beginning of the next epoch 
(j + 1). To see this, note that since at least 2/3 stake worth of the validators are honest, it is 


plausible that they all attest for B or a descendant (for example, if they are all synced with the 


network view and vote immediately after B is created). This creates a supermajority link LJ(B) 3 


(B, 7), justifying B. Now, in the next epoch (j + 1), it is plausible for the new block B’ with slot 
i+C = (j+ 1)C to include all of these attestations (which would happen with good synchrony), so 
Au i in(B’) isi stable at epoch (j+1). Thu 


and ho: : 


Thus, we can reduce our analysis to the case that c was stable to begin with, meaning that we have 
a supermajority link (B’,j — 1) > (B, j) in ffgview(B). Then by the same logic above, it is 
T 


ee E This finalizes the pair (B, j); in particular, it is the special 


case of 1-finalization. 


The original Casper FFG is a “finality gadget” on top of a (presumed probabilistically live) 
blockchain, so its focus was not on the probabilistic liveness of the underlying chain, rather that 
the participants do not get into a situation where we are forced to slash honest validators to continue. 
Since our paper also provides the underlying protocol, we also want a probabilistic guarantee of 
liveness, which we will cover in Section 7. 


7 Probabilistic Liveness 


In this section, we prove probabilistic liveness of our main protocol Gasper from Section 4, given 
some assumptions. Our proof consists of the following steps, which are basically the main ideas of 
the proof of Theorem 6.1: 


1. (assumptions lead to high weight after first slot) Under “good” conditions (such as having 
enough honest validators, synchrony conditions, etc. to be formalized) honest validators. 
have a high probability of finding a block with a high weight after the first slot. 


2. (high weight after first slot leads to high probability of justification) if we have a block with 
high weight after one slot, 


3. (high probability of justification leads to high probability of finalization) if every epoch is 
likely to sia a block, then it is very likely for at least one block to be finalized in a stretch 


This division is not just organizational; it also encapsulates the assumptions into different parts of the 
argument so that each part would remain true even if assumptions change. For example, the main 
theorem corresponding to the 3rd item, Theorem 7.5, does not make any synchrony assumptions 
and only relies on a probability p that a block gets justified (though synchrony assumptions may be 
required to bound p given the previous parts). Also, we assume in the second part (as we do for 
simulations in Appendix B) that all validators have equal stake, whereas the third part does not. 


This section is the most intricate and dependent on parameters: for oe die ameton 


‘consideration delay (see Section 8.4); also, , which may 


or may not be a useful assumption depending on external factors. However, it is still worthwhile to 
include an analysis for the “pure” protocol because the proof strategies here, such as using concen- 
tration inequalities, are very generalizable to a whole class of these potential slot-based approaches 
to proof-of-stake, and 
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` work probabilistically. In fact, “patches” such as the aforementioned attestation consideration delay 
exist primarily because of the types of attacks against the pure protocol, so it is useful for intuition- 
building to address these attacks even if the actual implementation sidesteps them. Thus, the primary 
value of this section is as a proof-of-concept of the analysis involved in designing probabilistically- 
live protocols such as Gasper, as opposed to a mathematical guarantee of the actual implementation. 


7.1 High Weight After the First Slot - The Equivocation Game 
We define the equivocation game to be the following: 


1. The game is parametrized by (V,a, €1,€2), where V is a set of validators and (a, €1, €2) 
are real numbers that parameterize network / synchrony conditions (for ease of reading we 
push the details to the Appendix). 


2. As in Gasper, |V| = N and each V € V has some fixed stake w(V). We assume the total 
stake is NV (so the average stake is 1) and the total amount of stake of honest validators is 
at least 2N/3. 


3. There are 2 options to vote for, which we call O, and O2 for short. These are abstractions 
for voting on 2 conflicting blocks in Gasper, and the concept of “blocks” are not included in 
this equivocation game. We (meaning the honest validators) win if either O1 or Oz obtain 

og 2 


The equivocation game is defined to capture the idea of Gasper with just 2 choices in one slot. Most 
of the necessary assumptions for liveness are encoded into the game so that the other liveness results 
in this section can be as independent as possible. 


In Appendix B, we flesh out the details of the equivocation game and conduct the simulations of 
equivocation game with three regimes (a pessimistic regime, an optimistic regime, and a regime in 
between). The main idea is tha 

me, meaning that we should expect one of the pairs in Gasper to 
have 2/3 worth of stake supporting it after the first slot. 


For the big picture, the only thing we need for the rest of Probabilistic Liveness is the idea that we 
“win” the equivocation game (specifically, have a block with a high number of attestations over the 
second-best option after the first slot) with some probability r, and having higher r increases the 
guarantees that a block will be justified in Theorem 7.4. For practical purposes, the work in the 
Appendix seems like an r of around 80% seems to be a reasonable heuristic under not too strong 
or weak synchrony conditions, and that is already assuming a very bad case where close to 1/3 of 
validators are dishonest. 


Remark. Clearly, the concept of equivocation games can be generalized, and similar games could 
be used to study other proof-of-stake models. There are many directions (the protocols for honest 
validators, latency modeled by something more than the uniform distribution, etc.) which may be 
interesting to study for future work, but may be too distracting for the purpose of our paper. 


7.2 High Weight after First Slot Leads to Justification 


In this section, we focus on the j-th epoch [T,T + C], where T = jC. Let S = N/C. We define 
the following set of assumptions, which we call A(e): 

e the network is (1/2)—synchronous starting at time T = jC; 

e each validator has 1 stake; 

e the total number of byzantine validators is equal to N/3— C'e, meaning the average number 


of byzantine validators in each slot’s committee is S/3 — €. 


For each i € {0,1,...,C — 1}, define h; to be the number of guaranteed honest attestors in slot 
jC + i and b; to be the number of dishonest attestors in the slot. Let S = N/C, so for all i, 
hi + bi = S. We show that the distribution of honest / dishonest attestors should not stray too much 
from expectation in Proposition 7.2, using ubiquitous concentration inequalities: 
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Proposition 7.1. Let ¥ = (21,...,a,) be a finite list of N values with a < x; < b and let 
Xj1,..., Xn be sampled without replacement from X. The following hold: 


7 ` —2n6? 
P (Exin le na) sl e a 


3 Y — 2n? 
P ($x -nE[X] < ~n) < exp (z a= cater 


Proof. See e.g. [19]. 


Proposition 7.2. Suppose the assumptions A(¢) are met. Assume that C = 2”. Then the conjunc- 
tion of the following events (we purposefully skip ho): 


Ey thy > 2-3 


E> tha +h3 > 2?- 3 


U 


Es : ha ths +he+h72 2. $ 


Er : hoya +: + hc- >24. 8 
has probability 
L L ; L 
21e? Qi? 
(f z) >1-$ ep e he Yep (-=5). 
i=1 i=l QL S i=l 
Proof. We use the hypergeometric distribution model; that is, we consider the set ¥ = 
(%1,-++ ,@N) representing the validators V, where x; = 1 if the j-th validator is honest and 0 
otherwise. Let X1,..., Xgi-1g be 2'-'S samples from Æ without replacement. Then for each j, 
1 < j < 2715, E [X;] = 2/3 + &/S, so: 
21 8 
2 | XO X;| =2°-19(2/3 + €/S) = 2'S/3 +27 te. 
j=1 


We can then bound each E; (as a sum of X;’s) by 


215 s Pe] s 
P D Ie, =1-P 2s 


= 2S € 
=1-P SEEN gi—1 0t 
> j ( se e) < -(2°18) 


Qe? 


eis 2i-1S—1 
EENE 


where the last inequality results from Proposition 7.1, recalling that N = 24.5. The probability of 
each event Æ; when considered independently of each other is then bounded below by this value. 
Using the intersection bound on all Æ; we get the first inequality in the desired statement; the second 
inequality holds by comparing denominators. 
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Remark. It suffices to also use e.g. Hoeffding’s inequality with a binomial model where the valida- 
tors are assigned as honest or byzantine with replacement. We leave it as an exercise to the reader 
that this method immediately gets the weaker bound 


L L Die? 
e(a) >1- ex (- 5 j: 
i=1 i=1 


While the binomial model is only an approximation, the model with replacement is strictly more 
mean-reverting than the model without, so the approximation is in the correct direction for us. This 
could be made rigorous with e.g. coupling methods. We use the weaker bound because it is alge- 
braically cleaner and loses very little compared to the stronger bound. 


It can be seen that the exponential terms in the result of proposition 7.2 is fairly small when € is on 
the order of VS. For example, when C = 64 (a power of 2 actually makes Proposition 7.2 work 
cleanly, though it is certainly not a crucial part of the bound) and thus S = 900, picking « = 30 
(meaning we have as many as 17280 byzantine validators out of 57600) gives a probability bound 
of around 85%; changing «€ to 40 jumps the probability to around 97%. 


Lemma 7.3. Suppose the assumptions in A(e) are met. Then, if view(NW, 7 + C) justifies 
a new block B not in J(view(NW,T’)), B must be a descendant of the last justified block in 
J(view(NW, T)). 


Proof. Recall that honest attestors wait for 1/2 time before attesting to their assigned slot. Thus, 
in the upcoming epoch j, all of the honest attestors in this epoch attest in the time period [T + 
1/2,T + C]. Because we have (1/2)-synchrony, it means their views during this period all include 
view(NW, 7’). By the nature of Algorithm 4.2, this means all of their block proposals and attestations 
must be to either: 


e a descendant of Bj, the last justified block in view(NW, T), or 


e a descendant of some new block justified in epoch 7. 


Our Lemma only fails in the second case, and if some new block in this epoch obtains 2/3 of the 
attestations of this epoch. 


Luckily, the chicken-and-egg favors us. It is possible for byzantine validators to propose a new 
block B’, that’s not a descendant of B z. However, it would be impossible for B’, to receive enough 
votes in this epoch, as all of the attestations before B’, is justified must go to a descendant of B; by 
Algorithm 4.2. Thus, we know that if we justify a new block, it must be a descendant of By. 


Theorem 7.4 (Justification Probabilistic Liveness). Suppose the assumptions in A(e) are met, and 
suppose we win the equivocation game corresponding to the first slot with probability r. Let By be 
the last justified block in J(view(NW, T)). Then, view(NW, T + C) will justify a new descendant 
of Byz with probability at least 


L n 
2e? 1 
Em > ep (-7) meaty 
i= 


Proof. We can think of the first slot of this epoch [T, T + 1] as an equivocation game with S val- 
idators (ho honest and by byzantine) where all of the options are B; or a descendant’ of Bz. Thus, 
with probability r, one of these options receives at least 25/3 attestations after slot jC. We call this 
winning block Bẹ (ideally, Bw is simply just the block jC, though this is not necessary). For sake 
of weighting in Algorithm 4.2, note that against any other option in the equivocation game, B.,,,’s 
weight is winning by at least (25/3 — S/3) = S/3. 


TAs stated in the proof of Lemma 7.3, it is possible that there are options that are not, but they will never 
receive attestations from honest validators, so it would be strictly worse for dishonest validators to create such 
options. 
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By the intersection bound, with probability at least 


L i 2 
r— > exp -3 ) 
i=1 


we also satisfy the events in Proposition 7.2. We now show that when these events are satisfied, all 
remaining honest validators in slots (jC +1),...,(7C-+C—1) will vote for B,, or a descendant. 


Consider slot jC + 1. Because of FE, we know bı < S$/3, so even if all bı potentially byzantine 
actors conspire to vote for some other option, the weight advantage of B,, cannot be diminished to 
0 by the time the honest validators vote at time (jC + 1.5). This means that all honest validators 
will keep attesting to B,, or a descendant block (an honest proposer in slot jC + 1 would propose 
block jC + 1 as a descendant of Bw, for example). By £1, we know that B,, gains at least 25/3 
weight while a rival block gains at most $/3 weight during this slot, which means that the weight 
differential preferring Bu changes by at least (25/3 — $/3) = 5/3. This means by the end of slot 
jC +1, By is now winning with at least weight S/3 + $/3 = 25/3. 


Now consider E» and the next 2 slots, jC +2 and jC +3. Between them, we know h2+h3 < 28/3, 
so even if all the byzantine actors conspire, they cannot destroy the winning differential of Bw, which 
by the end of these 2 next slots will be winning with at least weight (25/3 — 2.5/3+45/3) = 45/3. 


Inductively, this logic continues for all remaining slots in the epoch (specifically, all honest validators 
attest to Bu or a descendant. Here the structure of Algorithm 4.2 is important because while honest 
attestors may (and probably will) attest to new blocks, the weight of their attestations are added to 
that of B,, as well. 


We have thus concluded that during all remaining slots, B,, accumulates all attestations from honest 
validators. After slot jC, it has at least 25/3 votes with probability r. Then, we know it picks up 
weight at least hy + ho +--- + hc _1, for a total weight of 


Tj : 
2 a ee ee oe, 2 
=5+ > z= gets? 1) S = aan 


i=1 


so we indeed achieve enough weight for a supermajority link. 


To prove By is different from B,,, we need at least one honest validator to propose a new block 


on top of By before or in the first slot of epoch aep(B,,). Since Byz receives more than 2 of votes 


in epoch aep(B;), there are more than 3 honest validators in aep(B;). The chance of no honest 


validator proposing a block on top of B; in aep(B;) is then bounded above by ar which is 
vanishingly small. 


7.3 Probabilistic Justification Leads to Probabilistic Finalization 


The main theorem is the following: 


Theorem 7.5 (Finalization Probabilistic Liveness). Assume the probability of justifying a block (as 


in Proposition 7.2) is independently p > 1/2 for each epoch, 


Proof. Recall that we expect most finalization to be 1-finalization, when one justified block justifies 
an adjacent epoch boundary block. For this proof, it suffices to show that the probability of failing 
to even 1-finalize approaches 0. 


We consider an epoch a “success” if a block is justified in the epoch, and a “failure” otherwise. 
Thus, if 2 adjacent epochs are “successful,” we finalize a block. Therefore, the probability of not 
getting a (k = 1) finalization in n epochs is the probability that no 2 adjacent epochs out of the next 
n are successful. Using the independence assumption, this has the probability 


n— 
i> 3 
i+1 


n—i 


because for a particular i > n/2, there are ( ) ways to select ¿ failures. 
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Since p > 0.5, we know p > (1 — p), so the sum is bounded above by 


ed D| a-pa 


It is well-known (by e.g. induction) that: 


D i+1\ /n+1 z n E n—1 fa -F 
A kip \ 0 1 2 Bi 
the n-th Fibonacci number, which we know is of the form 
(a+v5)]" 1 [2] 
2 


1 


Fa = 
V5 


The second term vanishes as n — 00, so our desired quantity is bounded above by (times a constant) 


(1+ v5) eal 
2 


We have the bound ,/p(1— p) < 1/2 (by, e.g. AM-GM inequality), so the failure rate is bounded 


above by 
1 (/14+V5 
a . i: 


which goes to 0 as n — oo. Finally, recall that we are only looking at 1-finalization, so the chances 
of finalization is strictly higher (though in practice the other types of finalization should occur very 
rarely). 


root root root root root root 
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A A ry ry 
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Figure 7: The cases where we fail to finalize a block in n = 5 epochs with 3 failing epochs. “S” 
denotes success and “F” denotes failsure (with respect to Proposition 7.2. 


Theorem 7.5 is “agnostic” of the justification probability p and how we obtained it. This means 
if we tweak the protocol, change the assumptions, etc. and obtain different bounds/estimates for 
p than we do from the current Theorem 7.4, our result still holds. For this reason, we use p as 
an input to Theorem 7.5 instead of reusing our actual bound in Theorem 7.4. A secondary effect 
of abstracting away justification liveness is that the techniques can be used to prove finalization 
probabilistic liveness for general 2-stage protocols, not just Gasper (it could even be extended 
easily to protocols with 3 or more stages, though the bounding would be different). Regardless of the 
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protocol, as n increases, as long as p > 0.5, the probability of finalizing a block increases rapidly, 
getting around 99% even for p = 0.5 after n = 20 epochs. See Table 1 for some computations. 


Table 1: The probabilities of not finalizing blocks in n epochs, with p the probability of justification 
within each epoch. 


n |p probability of not finalizing any block in n epochs 
2 |05 | 0.75 

5 | 0.5 | 0.40625 

7 | 0.5 | 0.265625 

10 | 0.5 | 0.140625 

20 | 0.5 | 0.016890525817871094 
2 | 0.66 | 0.5644 

5 | 0.66 | 0.18460210239999997 

7 | 0.66 | 0.08322669164799996 
10 | 0.66 | 0.025351233503186934 
20 | 0.66 | 0.0004854107646743359 


Remark (Relationship with Plausible Liveness). It may feel like we technically get plausible live- 
ness “for free” from probabilistic liveness. So why do we treat them separately in this paper? 


For one, plausible liveness is an immediate consequence from the rules of the protocol Gasper and 
requires very few assumptions, while probabilistic liveness is dependent on probabilistic assump- 


tions ie as network Sumer and is more fagile with e changes to the protocol. In partic- 
ular, 
-——._ i Thus, we choose to present plausible liveness separately to emphasize that even if 


or another, 


is “new blocks will probably be justified/finalized quickly;” these are different takeaways. 


8 Practice versus Theory 


Ethereum 2.0’s practical implementation in [11] contains different design decisions from Gasper, 
which is meant to be a “clean” and more mathematically tractable protocol that captures the theo- 
retical core of the beacon chain design. In this section, we consider the proposed implementation’s 
differences from Gasper, without getting lost in the much messier analyses a rigorous study of com- 
bining all of these details would require. 


8.1 Sharding 


Gasper is motivated by the Ethereum 2.0 beacon chain, which is the “main” blockchain in the 
Ethereum 2.0 design that stores and manages the registry of validators. In this implementation, a 
validator is a registered participant in the beacon chain. Individuals can become a validator of the 
beacon chain by sending Ether into the Ethereum 1.0 deposit contract. As in Gasper, validators 
create and attest to blocks in the beacon chain. Attestations are simultaneously proof-of-stake votes 
for a beacon block (as in our design) but also availability votes for a “shard block,’ which con- 
tains data in a different “shard chain.” This concept of sharding creates interesting engineering and 
mathematical questions outside the scope of our paper, which is limited to the beacon chain. 


8.2 Implementing the View 


In Gasper, we can treat views and related concepts as abstract mathematical concepts and validators 
as perfectly reasoning agents with infinite computational power. In practice, validators will not be 
directly reasoning with a graphical data structure of a view; instead, they will use software to parse 
the view given to them and follow the protocol. Thus, in the actual implementation [11], validators 
run a program that updates the “store”, which is basically a representation of the view. The store, 
as the input for LMD GHOST fork choice rule, is updated whenever a block or an attestation is 
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received. The beacon chain also keeps track of a “state,” a derived data structure from the view that 
tracks stake-related data. 


Obviously, mistakes when interpreting these structures and their updates may cause issues with 
safety and liveness not related to those coming from Gasper itself. Even though in our work we limit 
our analysis to the mathematical parts of the protocol, we remind the reader these other issues are 
also important; security holes arising from from a carelessly implemented protocol at the software 
level are not protected by the mathematical guarantees of Gasper. — 


8.3 Attestation Inclusion Delay 


In Gasper, when a validator proposes a block, he/she includes all new attestations in his/her view. 


In the planned implementation, there is an integer parameter for the attestation inclusion delay (say 
n) such that SARA ESE TESTGE GES e TCE 


The purpose of the attestation inclusion delay is to prevent centralization and reward advantage. If 


the slot length is “short” (meaning the latency of attestation propagation is high for normal nodes 
in the network), then highly-connected nodes might be able to get attestation data faster and be 
able to publish them faster, which may correspond to various advantages depending on the reward 
incentives. 


blocks. Thus, nodes have more of an equal opportunity to capture the attestation inclusion rewards 


for proposing blocks. The plan is to tune tion inclusion delay (in the range of 1 to 4 slots) 
depending on real-world network data. Bie ene ee oe eee eee a 

-and larger values improve decentralization. Note increasing the slot time is an alternative method to 
promote decentralization. 


8.4 Attestation Consideration Delay 


In Gasper, when a validator is supposed to attest at slot JV, the validator runs the HLMD GHOST 
fork-choice rule considering all attestations in the validator’s view. In the planned implementation, 
he/she only considers attestations that are at least 1 slot old. Specifically, the view used as input 
to the fork-choice rule contains all valid blocks up to slot N but only contains valid attestations up 
through slot N — 1. 


This one-slot delay protects validators from a certain class of timing attacks in which byzantine 


This is an 
portant attack to counter as 
offense (since the adversary can theoretically fake timestamps and we did not assume Gasper has 
mechanisms that make faking timestamps harder). 


We cover the one-shot delay attack in our analysis of the equivocation game (see Appendix B), 
and conclude it i . However, the 


probability byzantine validators succeed in this particular type of attack is greatly lowered even in 
pessimistic regimes if we implement something like the attestation consideration delay. 


Specifically, this delay improves the parameters for probabilistic liveness as analyzed in Theo- 
rem 7.4. As long as an honest validator is selected to propose a block (with probability at least 
2/3 in the worst case) B, then all honest validators will vote for B in the first slot since they will 
ignore all the attestations made in the first slot, including those made by the dishonest validators. 
In other words, the attestation consideration delay neutralizes the 1-st slot equivocation game as a 
point of attack, meaning the probabilistic liveness of the proposed implementation comes with even 
better guarantees than raw Gasper. A rigorous analysis of the probabilistic liveness for this setup 
may make for interesting future work. 
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8.5 A Four-Case Finalization Rule 


While Gasper’s Definition 4.9 captures the “general” version of the mathematical idea of finaliza- 


tion, the proposed implementation uses a “reduced” version 
n particular, let B1, B2, B3, B4 be epoch boundary blocks for consecutive epochs, 


with B, being the most recent epoch boundary block. 


1. If Bı, B2 and B3 are justified and the attestations a that justified B3 have LJ(a) = By, 
we finalize B1. 
2. If Bo, Bs are justified and the attestations a that justified B3 have LJ(a) = Bo, we finalize 
Bo. 
3. If B2, B3 and By are justified and the attestations a that justified By have LJ(a) = Bo, 
we finalize Bo. 
4. If B3, B4 are justified and the attestations a that justified By have LJ(a) = Bs, we finalize 
3° 


These are special cases of Definition 4.9 for cases k = 1 (the first two) and k = 2. The idea here 
ig: EERSP SEO SUICS Hse IST AS GEA ESE OES. This means only epoch boundary- 
cblocks:mp to 2-epochsin the past ean benewty just arid TI NEALiZEa) ich gives the 4 cases. 


See Figure 8. 


Case 1 Case 2 Case 3 Case 4 
Aa Bı Bı Bı 

B2 L) B | Bə 

Bs Bs Bs B3 

B4 Bı Bs Ba ) 


Figure 8: From left to right, example of cases 1 to 4 respectively. Both red and blue colors indicate 
justified blocks, where the blue blocks are now finalized because of the observed justification, shown 
by double arrows. 


8.6 Safety - Dynamic Validator Sets 


In Gasper’s safety analysis (Section 5), we assumed static validator sets, meaning the set of valida- 
tors cannot change over time. Recall our main result, Theorem 5.2, tells us we are able to catch 
N/3 weight worth of validators violating the slashing conditions if safety is broken. However, in 


practice, we would like to support dynamic validator sets, which means 
aaiae Cha TRESS N This means byzantine 


This setup reduces the number of “active” 
validators we can punish for violating slashing conditions. 
Definition 8.1. Assume there are 2 validator sets, V4 and V2, where Və is a validator set later in 
time compared to V,. We define A(V,, V2), the validators who activated (from V, to V2), to be the 
set of validators who are not in V; but are in V2, and E(V1, V2), the validators who exited (from Vı 
to V2), to be the set of validators who are in V; but not in Və. 


First, we note that our key ideas from Section 5 still hold: 
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Lemma 8.2. Suppose we allow dynamic validator sets. In a view G, if (By, fı) and (Bo, f2) in 
F'(G) conflict, then the blockchain must be (1/3)-slashable. Specifically, there must exist 2 justified 
pairs (Br, jr) and (Br, jr) in G and 2 subsets Vı C V(Br), V2 C V(Br), each with weight at 
least 2/3 of the stake of its corresponding attestation epoch, such that their intersection Vi N Və 
violates (S1) or (S2). 


Proof. The proof is essentially identical to that of Lemma 5.1 and the reduction of Theorem 5.2 to 
it. The only difference is that we must rephrase the conditions of Lemma 5.1 as conditions about the 
validator sets at the time of their attestations. 


As in the proof of Theorem 5.2, if we have 2 conflicting blocks (Bi, fı) and (Ba, f2), then either 
fi =foor fi # fo. If fı = fo, then we can set (By, jr) = (B1, fi) and (Br, jr) = (B2, f2) to 
satisfy our claim, as their intersection violates (51). If fı 4 f2, without loss of generality, fı < fo. 
Since (Bo, f2) is finalized, it is also justified, and we now satisfy the the setup for Lemma 5.1 where 
(Br, f) = (Bi, fi) and (By, j) = (B2, fo). Applying the Lemma, we conclude that either Bo is a 
descendent of B, (a contradiction as they are conflicting), or there must be some pair of pairs (not 
necessarily (Br, f) or (Bz, j) themselves), each of whose attestations have 2N/3 stake, and whose 
intersections violate (S1) or (S2). 


We now present our main theorem. The main idea is to first take a block Bo (most naturally, we can 
take the common parent of the conflicting blocks, but this choice is not necessary) published at a 
“reference time” with a “reference validator set” Vo. Then, we can upper bound the total weight of 
activations and exits between the validator sets of the justified blocks Bz and Bpr (from Lemma 8.2) 
and Vo as a function of the elapsed time since the referenced time. This allows us to lower bound 
the size of the slashable intersection of the quorums of those blocks. 


Theorem 8.3. Suppose we have a view G which contains two conflicting finalized blocks, then G 
has enough evidence to slash validators with total weight at least 


max(w(Vz) TUL — er, w(VR) SERT eL) bors w(Vz)/3 E w(VR)/3, 
where 


1. there is a block Bo € G with validator set Vo; 
2. blocks By and Bp exist by Lemma 8.2, with validator sets Vz and Vp respectively. 


3. ay = w(A(Vo, Vz)) and ez = w(E(Vo, Vz)); similarly define apg and ep. 


Proof. By assumption, the pair of (unnamed) conflicting finalized blocks give rise to By and BR 
with Lemma 8.2, which in turn have quorums Qz C Vz and Qr C Vr, both with at least 2/3 of 
the weight of their corresponding validator sets Vz and Vp. 


We denote the different sets created by the overlap of our 3 validator sets to be A, B, C, D, E, F, G, 
as in Figure 9. 


Next, we wish to bound the intersection of the quorums Qz, and Qp as depicted in Figure 10. Let 
Vir = VL AN Vr = C U F, we have: 
w(QLN QR) > WRL N Vir) +w(QrRNVrr) — w(CU F) 
> 2w(Vz)/3 — w(B U E) + 2w(Vr)/3—- w(DUGU CUF) 
= 2w(Vz)/3 + 2w(Vr)/3 — (wW(BU CU DU EU FUG)) 
= w(C) + w(F) — w(Vz)/3 — w(Vr)/3. 
Let X = w(C) + w(F). We know 
X =w(Vz,) -—w(BUE) 
>w(V_) -wAUBUEUF) 
= w(VL)— aL — er, 


and similarly 


X > w(Vr) —aR-— EL. 
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Figure 9: A Venn diagram of the initial validator set Vo and two validator sets Vz and Vp, the letters 
A through G pictorially represent how many validators are in each overlap. 


Vi Vr 


Figure 10: The quorums Qz and Qpr have overlapping validators between the conflicting blocks Bz 
and Br. 


As a sanity check, note all the a’s and e’s are zero in the extreme case of no exits or activations, so 
we recover the original bound of w(V,)/3 = N/3. Also, we can avoid negative signs by e.g. using 
a linear combination of the two bounds for X to get the bound 


w(Vz)/3 — (2a, /3 + 2er/3 + ar/3 + ey /3). 


The power of the bound depends on our policies on activating and exiting. Suppose Bo, the “refer- 
ence block” was published at time Jy, and Bz and Bp are published at Throw (more precisely, we 
should define T;,5,, to be the maximum of the two blocks’ publication times). Then we can control 
the a, and e, as a function of the time difference and the policies. Here are some examples and 
observations: 


e If we allow a constant stake of k worth of new validators to activate per epoch, then we can 
bound 


aL,AR < k (Taon T To) 4 


We can do the same with exiting and obtain bounds on ez and ep, possibly with a different 
constant in the same protocol. 
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e If we allow activating proportional to validator stake, e.g., up to k - w(V) can activate in 
one epoch, then the bounds become exponential: 


ap, aR < w(V)(1 +k) To; 


In the limit this becomes an exponential bound. 


e As the difference between Tnhow and Ty becomes longer, the w() terms will get big and the 
bound becomes less useful, with the right-hand-side eventually becoming negative. This 
is unavoidable; one can imagine a “ship of Thesesus” situation where the validator sets 
have changed completely, in which case it would be impossible to slash anyone still in the 
system. 


e The bounds can also take care of latency; if we are prepared for up to time 6 of latency, 
then we effectively add ô to computations where (T;,ow — To) occur in our bounds of a’s 
and e’s, which we can then feed back into Theorem 8.3. 


These bounds show a tradeoff between the flexibility of entering and exiting the blockchain and 
the ability to catch malicious actors. Our static result, Theorem 5.2, has the intuition “if our proto- 
col breaks safety, we can provably slash 1/3 worth of validators” to imply safeness of our protocol 
as long as we have a strong enough belief in the validators. Our dynamic result, Theorem 8.3, is 
of the more nuanced form 


This means pure 


. Such situations 


Gan be sa gearless psaatioes nore plsemoe ni inane Barat one TOES: the current 
Ethereum 2.0 spec, for example, does not accept attestations 2 or more epochs old, which avoids 


this attack. 


8.7 Extreme Cases; Hard Forks 


Even though 
it is important to take into account of worst- 


case scenarios. In the case of extended forking and: lack of finality due to lots of non-live (non- 
participa. tha AEA thus not slashed), the Ethereum 2.0 
beacon chain has a mechanism by which live ae aie ee 


> 


ome a Z 
cepa dpopotheodezofmaniudeebueska Such a case may happen if, e.g., the global 
internet is partitioned such that 50% of validators are on one side and 50% on the other. 


A different extreme case is where a chain “flip-flops” continuously suc 
partition, and instead the majority just keeps switching forks each epoch. 


(famous such cases include 
Bitcoin vs. Bitcoin Cash, or ETH vs. ETH Classic). This might be due to upgrading or adding 
features, fixing critical issues in production, or addressing a fractured community or political split. 
Usually, this results in a new set of protocol rules being run starting at some particular point in the 
blockchain. Itis an important engineering problem, again outside of our mathematical scope, that the 
state transition and fork-choice functions can handle these changes smoothly. In most considerations 
the HLMD GHOST fork-choice rule would be untouched. However, when the alterations are “deep” 
inside the logic, considerations beyond the built-in forking mechanism would have to be taken and 
manual forks might be implemented. 


9 Conclusion 


We presented an abstract protocol, Gasper, that combines LMD GHOST and Casper FFG for a full 
proof-of-stake based blockchain design. This is the first formal proof-of-concept of Casper FFG to 


SFor reference, it takes roughly 2.5 months in the concrete protocol to turn over 1/3 of the validator set, 
given the queuing mechanism in the Ethereum implementation, which is on the order of 20000 epochs. 
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a complete blockchain protocol. Our goal was to separate the “mathematically clean” part of the 
Ethereum 2.0 design from the implementation details. Some of the analytical techniques are general 
enough to be useful for studying other protocols, such as the proofs of probabilistic liveness and the 
equivocation game construction. In practice, much of the worst-case worlds from the analysis can 
be patched by ideas such as in Section 8. 

For transparency, it is important to note that it is possible for “patches” or even “implementation de- 
i However, it is impo ential implementation changes 
the protocol will eventually receive, or which of the current proposed patches would be included 
or removed from implementation for possibly unrelated reasons. Thus, we wrote this paper to an- 
alyze the main theoretical foundations of the protocol and we simply sketched an analysis of each 
implementation detail as an isolated change instead of in conjunction with others. As the protocol 
solidifies, possibly with real-life testing, it would be meaningful to reassess the effects of patches 
that would become “core” to the protocol. In particular, some version (possibly significantly differ- 
ently from what we proposed) of dynamic validator sets would be indispensable; once its design is 
finalized, it would be important to revisit the safety/liveness implications. 


There exist many other proof-of-stake based protocols in the cryptocurrency space. Some examples 
include: 


e Tendermint [4]: a very “pure” design that is a simplification of PBFT applied to a 
blockchain proof-of-stake context. This design favors safety over liveness. All validators 
participate in every consensus round and no consensus happens faster than those rounds, 
with progress only possible if > 2/3 stake worth of validators are online. 


e Casper CBC [5]: an alternative proposal to Casper FFG, focusing on mathematical cor- 
rectness by construction. Casper CBC does not have fixed in-protocol thresholds, based 
on an emergent approach to safety arising from nodes following the majority of what other 
nodes have done in the past and making finality inferences about blocks. Besides being 
a proposed protocol, Casper CBC is also meant to be a general framework for analyzing 
consensus designs. 


e Hotstuff (v6) [21]: has many similar properties as Casper FFG, with a flexible mathematical 
framework; one key difference is that Hotstuff uses an exponential backoff mechanism to 
be able to make progress under arbitrary network delays. 


e Ouroboros [14]: a protocol under the “synchronous” school which assumes synchrony for 
fault-tolerance (and thus gets stronger 50% bounds for fault-tolerance). It uses the longest- 
chain rule and reward mechanisms to incentivize participation and prevent passive attacks. 
In Ouroboros Praos [14], the protocol is updated in response to vulnerabilities against “mes- 
sage delay” attacks. In Ouroboros Genesis in [1], the protocol is further expanded to allow 
for the ability for a participant to bootstrap the consensus from the genesis block (hence the 
name), proving globally universally composable (GUC) security against a 50% adversary. 


e Snow White [9]: a protocol where the committee leader can extend the blockchain with a 
block that includes a reference to the previous block, similar to block dependencies, and a 
nonce that can be used to verify the block’s validity against some a priori difficulty constant. 
Valid timestamps must increase and “any timestamp in the future will cause a chain to be 
rejected”. Participants only accept incoming chains that have not been modified too far in 
the past, similar to accepting views within a certain number of epochs. 


e Nxt [16]: a proof-of-stake protocol that has a finite number of tokens. Nxt uses a stake- 
based probability for the right to generate a block, but it imposes transaction fees to circu- 
late currency since it does not generate new tokens. Nxt contrasts themselves from Peer- 
coin, noting that Peercoin’s algorithm grants more power to miners who have had coins 
on the network for a long time. The protocol also describes certain restrictions on block 
creation and transferring tokens to prevent standard attacks and moving stake between ac- 
counts. 


e Thunderella [18]: a proof-of-stake protocol that aims to achieve optimal transaction verifi- 
cation relative to message delay, assuming “good conditions” that the leader of a committee 
is honest and has a super-majority of honest validators. A new leader will be implemented 
to build upon a back-up network in the event of a stall. The protocol also allows for dy- 
namic validators with cool-down periods. 
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e Dfinity [12]: beacon-notarization protocol that works with both proof-of-work and proof- 
of-stake. The system uses a random beacon that selects block proposers, and a decentral- 
ized notary chooses the highest-ranked block based on a criteria described in [12]. Their 
analogues of validators and committees are called replicas and groups respectively, and 
the decentralized notary depends on the same Byzantine fault-tolerance to notarize blocks 
and reach consensus. They only have a passive notion of finalization, but the notarization 
process is quite fast, and blocks do get published in a timely manner. Replicas do need 
permission to leave the chain. 


Our goal is not to show that our design is strictly better than any of these other designs. All of these 
protocols contain tradeoffs based on different design goals and assumptions about the network. Our 
design is guided by a balance between simplicity, understandability, and practicality, with a mixed 
emphasis on safety and liveness. For example, if the context of a proposed blockchain prioritizes 
safety over speed, then one may, e.g., select or modify a proposal more in the direction of Tender- 
mint. 
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A Technicalities of Views 


In Section 2, we defined view in a streamlined treatment. We provide a more detailed treatment in 
this section that offers further intuition. 


First, we give a different definition from view that should seem more intuitive to some readers. We 
define th 


t We can denote the full view as fv(V,7). Similarly to the 
network view view(NW, T), we also define a “God’s-eye-view” fv(NW, T), the as 


As with views, 

for any validator V and any given time T, fv(NW, T) includes all the messages for any fv(V, T), 

With this definition, our definitions view(V, 7) and 

view(NW, T) respectively are just subsets of the accepted messages in fv(V, T) and view(NW, T) 
respectively. 


Now, it is completely possible to describe everything in terms of full views instead of views. How- 
ever, there are many reasons why we work with views instead of full views in this paper (and why 
we leave the concept of full views to the appendix). To give a few: 


e We can visualize views as a connected tree of blocks and attestations (with edges corre- 


sponding to depe cies). T 
pee eee aE 


e Motivated by real-life concerns, a protocol working with full views would have to contain 
instructions that differ on how to handle messages a validator V has seen (but shouldn’t act 
on, as it depends on a possibly nonexistent message V has not seen) versus a message a 
validator has accepted and fully “understands”. As an example, a cryptocurrency protocol 
may have to contain statements of the sort “when a full view sees a transaction about 
a coin B, if the parent blocks of B exist (recursively) and are all signed correctly, then 
consider the transaction valid.” This is very clunky, whereas if parent-child relationships 


were dependencies then using views abstracts away the recursive-checking logic, and we 


just need to say “when a view sees a transaction about a coin B, consider the transaction 
valid.” 


e It is always possible to have a protocol that works on views: if message B depends on 


message A but we receive B first, then working with views is equivalent to ignoring the ex- 


i ncies) 
© 


To summarize: even though the full view is somewhat intuitively easier to understand than the view, 
since all the dependencies are met in a view by construction, i 


C 2°12 reasoning about 
the full view will usually come with caveats about checking that all dependencies of the messages 


involved in the reasoning are met (probably recursively). 


B The Equivocation Game 


Recall that in Section 7, we abstracted a single slot of Gasper into a one-shot game called the 
equivocation game, parametrized by (V,a, €1,€2), where V votes on 2 options O; and Og. In this 
Appendix, we give some further details and perform some simulations. 


First, we explicitly discuss how time and synchrony conditions are modelled in this game: 


1. There is a single time period in this game, formalized as the real interval [0, 1]. This interval 
corresponds to the 1 slot of time in Gasper. 


2. Honest validators follow the following protocol: ‘ 


more total stake voted in your view; in the case of a tie, vote O,.” This protocol corresponds 


to the instruction in Gasper that attestors for slot i are supposed to attest at time i + 1/2 
(and tiebreakers are broken by a hash, which is an arbitrary but fixed value). 


3. Synchrony model: 
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(a) We assume that all validators have perfectly synced clock 
rounding to inside the interval 
(0, 1)), ert 
We can think of € as a “timing error” ound, account- 
ing for clock differences, client-side timing issues, etc. 
(b) When a validator votes at “real” time t’, all other validators obtain the vote at time 
`t +a+/Y, where i . We 
can think of a as the average delay per message, 
Combining with the previous point, we have that a validator attempting to vote at time 
t actually has his/her vote received by another validator at t + a + X + Y, where the 
X and Y are independently re-sampled for each event. 


For our analysis in this section, we make the following additional assumptions and notations: 


e Every validator has exactly 1 unit of stake. Barring further knowledge (such as empirical 
data) about validator stake distributions, this is the most intuitive choice for our toy model. 


e We define N, > 2N/3 to be the total number of honest validators (which is equivalent to 


their total amount of stake). In reality (and in Section 7), we expect Np to be a bit bigger 
at 2N/3 + eN for small e. 


e Similarly, we define Np < N/3 to be the number of byzantine validators. We use p = Ae 
to be the proportion of byzantine validators. 


Finally, for our computer simulations, we additionally set the parameters to V = 111, Ny, = 74, 
N, = 37. The total number of validators of 111 is based on [6], as a heuristic lower bound for 
making the committees safe. Erring on the conservative side, we pick the maximally pessimistic 
parameter of p = 1/3 fraction of byzantine validators. Having more honest validators than this 
assumption significantly improves our chances of winning. 


B.1 The Pessimistic Regime - High Latency 


This pessimistic regime is a mental experiment to show that under certain conditions fair to both 
We assume that « (the delay for messages from one validator to another) ' Canepa (the 


error in timing a vote). In this situation, we argue that the dishonest validators can perform the 


following * j: 

th or a total of pN /2 votes for each option, all with fake 
timestamps for time close to 0.5. 

When this attack activates, from the view of each honest validator, at time 0.5 they will see some 
random votes from the dishonest validators. As a is big compared to €, they almost never see 
s. Thus, t i i i 


e dishonest validators end up splitting pN of the votes, and the honest validators 
split the remaining (1 — p) N probabilistically. 


Assuming the honest validators all have 1 stake, the honest validator’s votes can be modeled by 
(1—p)N Bernoulli trials between the two outcomes, ending up close to a normal distribution around 


a tie, with a standard deviation proportional to ,/(1 — p)N votes. In particular, for large NV, it is 
. i $ 


Remark. As an extension of this example, we can also consider the case where the protocol 
tiebreaker is “flip a coin,” the situation becomes even worse: the dishonest validators can simply 
wait until the end to vote. Because a is big compared to €14, the honest validators are still essentially 
making coin flips since they have not seen any other votes. Our tiebreaker rule (vote for option O, if 


there is a tie) solves this problem. The main takeaway here is that these protocols (including attacks 


In Figure 11, we have four cases that demonstrate different outcomes of the pessimistic regime with 
a = 0.15, €; = 0.05, and €2 = 0.15. This ensures that messages sent at time t are received uniformly 
randomly in the interval [t,t + 0.3]. Note that 

a ; ; 
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In Case 1, dishonest validators vote much earlier than honest validators do, so most of the attestations 
made by the former are visible to the latter when they vote. Thus, the honest validators are likely to 
vote for the same option. For Cases 2 and 3, dishonest validators vote closer and closer to when the 
honest validators do, which increases the power of the attack; in Case 3 dishonest validators win at 
42% of the time. In Case 4, dishonest validators vote at the same time as honest validators; because 
of the delay, the dishonest votes do not confuse the honest validators, so honest validators almost 
always win (because they are likely to vote for the default option O1, barring seeing any votes). 


e 
0 0.15 0.25 0.45 0.55 1 
e 

0 0.25 0.35 0.45 0.55 0.65 1 
——_— 

0 0.25 0.35 0.45 0.55 0.65 0.75 1 
l e—a e oO 

0 0.25 0.35 0.45 0.55 0.65 0.75 0.85 1 


<_> _: dishonest validators’ voting time frame 
<_> : honest validators’ voting time frame 


* œ à interval of possible time to obtain dishonest validators’ votes 


Dishonest voting time Win 
0.2 96% 
0.3 74% 
0.4 58% 
0.5 100% 


Figure 11: Pessimistic regime simulations with a = 0.15, €; = 0.05, €2 = 0.15 for the 4 cases above 
in order. Each row has a different coordinated dishonest voting time, which affects the winning rates 
of honest validators. 


B.2 The Optimistic Regime - Low Latency 


For this regime, we go to the other extreme and assume perfect synchrony (a = ¢2 = 0). This means 


In this game, the moment one choice has a lead (by default, O1 
all honest validators will vote for the choice in the lead. Thus 

ie (in which case the next honest validator will vote for 
O1) or such that Oz has one extra vote (in which case the next validator will vote O2). However, as it 
takes more votes to get the count to under Oj, 


. In our situation wher is gives a total vote differential of 
1—2p)N = N/3, which is good for us. One can see a simulated outcome of this case in Figure 12. 
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0 0.25 0.35 0.45 0.55 0.65 0.75 0.85 1 


Figure 12: Optimistic regime simulation outcome with a = 0, €; = 0.05, €2 = 0 with both dishonest 
and honest validators voting in the same time frame. Honest validators always win. 


B.3 An Example Inbetween 


We make a specific set of assumptions somewhere between the extremes presented in sections B.1 
and B.2. These assumptions are fairly arbitrary and hopefully presents a realistic example. It would 
be good to find principled “bottom truth” parameters somehow (such as after the actual blockchain 
is implemented). 


In Figure 13, we have three cases that demonstrate the outcomes of the inbetween examples with 
a = 0.1,€, = 0.05 and e2 = 0.1. Thus, a is comparable to «; (avoiding the pessimistic case) 
R avoiding the desis case). 


In Case 1, some dishonest validators vote earlier than honest validators do and their “smoke bomb 
attack” has some impact; however, the amount of votes are not distracting enough compared to the 
amount of votes honest validators are able to vote following the protocol. In case 2, as we earlier 
discussed in the pessimistic regime, dishonest validators vote closer to when the honest validators 
do, which boosts the effectiveness of the attack. In Case 3, dishonest validators vote at the same 
time as honest validators do; as in the pessimistic regime, honest validators still almost always win. 


e de o 
0 0.25 0.35 0.45 0.55 1 
e a 
0 0.35 0.45 0.55 0.65 1 
e d o 
0 0.45 0.55 0.65 0.75 1 
Dishonest voting time Win 
0.3 93% 
0.4 79% 
0.5 99% 


Figure 13: Simulation outcomes with a = 0.1, €, = 0.05, eg = 0.1. 
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